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A programmed BasicCard is used as the starting point in this article. We 
show how this ‘SIM card emulator’ can be adapted to test the most 
important functions that are available from the normal menu and the ser- 
vice menu of certain GSM phones. 


Satellite 4090XCDT. 


The SIM (Subscriber Identification Module) 
card is the indispensable key for the use of 
every GSM phone. It contains both secret 
codes as well as personal details of the user 
and is supplied to the customer by the net- 
work operator, who usually retains the own- 
ership rights. 
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A Smartcard using an open Oper- 
ating System, such as the BasicCard, 
can be modified into an experimen- 
tal SIM card, which allows a large 
number of experiments to be done 
independently from the network 
operators. 


The ‘professional’ 
BasicCard 


Since the introduction of the ‘com- 
pact’ BasicCard in 1998, the German 
company ZeitControl (www.zeitcon- 
trol.de) have developed more power- 
ful versions such as the ‘enhanced’ 
and the recently introduced ‘profes- 
sional’ version. The ZC 4.1 has 
reached a new milestone, because 
this is the first BasicCard that sup- 
ports the T=0 protocol. All previous 
versions of the BasicCard would 
work solely with the T=1 protocol, 
which is widely used in Germany. 

Because the GSM 11.11 specifica- 
tion by ETSI requires the use of the 
T=0-protocol, it wasn’t possible up 
until recently to use the BasicCard in 
a GSM phone. 
The ‘professional’ BasicCard con- 
tains one of the most powerful 
ATMEL processors: the 
AT90SC323C. It has 32 KB of Flash 
memory for use by the operating 
system, 32 kB of EEPROM memory, 
1 kB of RAM and a cryptographic 
coprocessor. This makes the chip 
very suitable for use as a ‘Phase 2’ 
SIM card and a ‘SIM Toolkit’. 

The most remarkable property of 
this chip is the fact that it has been 
wholly designed around Flash EEP- 
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Table |. 
Overview of the standard 
GSM I1.11 instructions. 


20h : verify CHV 

24h : change CHV 

26h : disable CHV 

28h : enable CHV 

COh : get response 
32h : increase 

04h : invalidate 

BOh : read binary 

B2h : read record 

44h : rehabilitate 
88h : run GSM algorithm 
A2h : seek 

A4h : select 

FAh : sleep 

F2h : status 

2Ch : unblock CHV 

D6h : update binary 
DCh : update record 
10h : terminal profile 
C2h : envelope 

12h : fetch 

14h : terminal response 


ROM technology. The on-chip oper- 
ating system is loaded into memory 
during the activation of the card 
and is no longer mask programmed 
into the ROM area of the card. This 
gives the card much greater flexi- 
bility in use. 

In a conventional SIM card the 
operating system is stored in ROM 
and can therefore not be modified. 

The EEPROM contains an operat- 
ing system that complies with the 
GSM 11.11 specification and (for 
‘Phase 2+’ SIM cards) possibly some 
SIM Toolkit applications (usually 
Java applets), which have been 
added by the network operator or 
other institutions (such as banks). 

The BasicCard has an open oper- 
ating system, just like Javacards, 
Multos and other ‘Windows for 
Smartcards’. In this case it is an 
interpreter that makes it possible to 
write applications in the ever-popular 
BASIC language, although this ver- 
sion has been specially adapted for 
use with these Smartcards. 

When we've reached the point 
where the applications have to be 
transferred into the EEPROM, this 
can be done using a powerful, but 
still free, development tool 
(www.basiccard.com). 

The BASIC program of nearly 450 
lines used for this project takes up 
about 17% of the EEPROM memory, 
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with the remainder being shared 
between the GSM 11.11 compatible 
files and a large log file, where the 
card can keep a record of all external 
instructions received. 


The SIM card emulator 


It certainly isn’t the intention that 
the SIM card emulator is used to 
make telephone calls. Its main use is 
to make a number of functions 
accessible, which can usually not be 
realized with a card from the net- 
work operator. 

In a real SIM card most of the sen- 
sitive information is protected 
against being overwritten and some- 
times even against being read, 
through the use of administrator 
codes that are only known to the 
network operator. 

In the scope of this project all con- 
fidential information (including the 
PIN code of the subscriber) is per- 
manently deactivated, leaving us 
with complete access to the existing 
data. 

If you think that it is easy to copy 
the information from a valid SIM card 
to make a usable clone, you would 
be very wrong. There are two pro- 
tective measures in our project that 
make it impossible to use it for fraud- 
ulent purposes: 


— To start with, the (A3/A8) coding 
algorithm that guarantees the 
validity of SIM cards on the GSM 
network is completely bogus in 
this card and can't be modified. 

— You can try to make a copy of a 
working card, but the secret code 
is stored in a part of the card that 
can absolutely not be read. 


One of the niceties of this card is that 
it provides access to hidden menus 
in some phones (especially so in 
Motorola phones), which are other- 
wise only accessible to authorised 
technicians. 

The card is not suitable to recover 
lost security codes or to activate 
functions that are concerned with 
the cell information of transmitters of 
the various networks in a particular 
area. 

There is enough EEPROM mem- 
ory in the card to store all instruc- 
tions sent to it by a phone or another 
terminal in an internal file. (Another 


terminal could be a PC running a program for 
accessing SIM cards). When this log file is 
subsequently transferred to the PC, it can be 
analysed for instructive or diagnostic reasons. 

Finally, our card is also ‘Proactive SIM’ 
compatible, which means that it (as opposed 
to simple Phase 1 or 2 SIM cards) not only 
deals with the instructions sent to it by the 
phone, but can also initiate actions in the 
phone, particularly concerning the display 
and sounder. 

The card has a small self-contained pro- 
gram, which only works in Phase 2 compatible 
phones. After about a minute this returns a 
hexadecimal string on the display (the ‘Ter- 
minal Profile’), which after decoding provides 
a detailed list of the capabilities of the ‘SIM 
Toolkit’ of the phone. Next, the card starts to 
interfere with the workings of the phone 
(without disrupting the normal operation 
however), momentarily showing ‘BasicCard’ 
on the display once per minute, whilst play- 
ing a melody. 


The card in detail 


The SIM card emulator recognises all the 
standard instructions that can currently be 
sent by GSM phones (see Table 1) for 
Phase 1, 2 and 2+ standards. ‘Recognises’ 
does not necessarily mean ‘processes’, espe- 
cially where instructions are concerned that 
access personal details. Even when the card 
ignores an instruction completely, it will 
return a successful reply to keep the GSM 
session from stalling. 

For example, when you activate the PIN 
code function, the card will respond with the 
generic success code (9000h), but then won't 
request the PIN code. When we attempt to 
change the PIN code the card will also reply 
that the operation was carried out success- 
fully, but any PIN code will be accepted as 
the correct one. 

This trick makes it possible to play with 
the contents of the card without restraint. 
Before we get to that stage we should explain 
the structure of GSM-instructions a bit more, 
so that we can interpret the contents of the 
log file. 

For SIM cards working with the T=0-pro- 
tocol, all instructions destined for the card 
begin with a five-byte header: CLA INS P1 P2 
LEN. 

CLA is the ISO class of the instruction, which 
for a SIM card always has the value AOh. 
INS is an operational code of which some val- 
ues are shown in Table 1. 

P1 and P2 are two parameters whose con- 
tents depend on the operational code used, 
but which usually have a default value of 00h. 
LEN holds the length of the data block that 
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follows, or OOh if there is no data block. 

There is a distinction between incoming 
instructions (from phone to card; the data 
block is sent after LEN) and outgoing instruc- 
tions (from card to phone; the card is 
requested to send LEN bytes of data). In 
nearly all cases the card returns a minimum 
of two bytes, the Status Code (SW1 and SW2, 
which are 90h and 00h respectively on a suc- 
cessful completion). 

Should the card wish to return data in 
reply to an incoming instruction, it answers 
with SW1=9Fh, with SW2 containing the 
number of bytes that should be requested 
with the instruction ‘GET RESPONSE’ (A0 CO 
00 00 SW2). 

The T=O0-protocol has the property that it 
does not support the simultaneous transmis- 
sion of incoming and outgoing instructions, 
which is possible with the T=1 protocol. This 
property makes it much simpler to use. 

The most often used instruction is 
undoubtedly ‘SELECT’. This is used to navi- 
gate through the directory structure, in a sim- 
ilar way to the old MSDOS instruction, ‘CD’ 
(Change Directory). 

The root directory (address 3F00h) con- 
tains the following subdirectories: 
7F 10h (Telecom) 
7F20h (GSM) 
7F21h (DCS, a copy of the GSM directory, 
which is used by 1800 MHz phones). 

To change to the ‘Telecom’ directory from 
the root directory, the following instruction 
should be issued: 

AO A4 00 00 02 7F 10. 

Table 2 gives an overview of the files that 
are in the various directories on our card. 
Some of the files are vital to the operation of 
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Table 2. 
The files on our card. 


Root directory: 
2FE2 (ICCID) 


Telecom directory: 


6F3A (ADN, Abbreviated Dialling Numbers) 
6F3B (FDN, Fixed Dialling Numbers) 


6F3C (SMS, Short Messages) 
6F40 (MSISDN, Own Numbers) 


6F42 (SMSP, Short Messages Service Parameters) 


6F43 (SMSS, SMS Status) 


6F44 (LND, Last Number Dialed) 


GSM or DCS directory: 


6F05 (LP, Language preference) 


6F07 (IMSI, International Mobile Subscriber Indentity) 


6F20 (Kc, Ciphering Key) 

6F30 (PLMN, Preferred PLMNs) 
6F31 (HPLMN search period) 
6F38 (SST, SIM Service Table) 


6F3E (GID1, Group Identifier level 1) 
6F3F (GID2, Group Identifier level 2) 
6F74 (BCCH, Broadcast Control Channels) 


6F78 (ACC, Access Control Class) 


6F7B (FPLMN, Forbidden PLMNs) 


6F7E (LOCI, Location Information) 
6FAD (AD, Administrative Data) 


6FAE (Phase) 


a GSM session; the other files can be 
used for interesting experiments. 

Once a certain file has been 
selected its contents can be 
processed using read instructions 
(read binary, read record...) or write 
instructions (update binary, update 
record...). 

In order to use the card to its full 
potential you would obviously have 
to know the function of all the files 





on the card. Although the only offi- 
cial description of the GSM specifi- 
cations (www.etsi.org), and in par- 
ticular the section on GSM 11.11, has 
very detailed explanations, we will 
limit ourselves to just the essential 
parts. 

We will concentrate primarily on 
the GSM (or DCS) directory, which 
has the most potential for informa- 
tive experiments. 

The Phase and SST (SIM Service 
Table) files play an important role in 
the extent to which the phone 
returns information regarding the 
capabilities of the card (in reply to 
‘Terminal Profile’ that is sent by 
some phones). 

The ‘Phase’ file consists of a sin- 
gle byte, with a value of 02h for 
Phase 2 or 03h for Phase 2+, and is 
usually nonexistent in SIM Phase 1 
cards. In contrast, the SST file will be 
larger for SIM cards offering more 
capabilities. Every service that is 
supported by the card is realised via 
two bits, which indicate whether or 
not the service in question is present 
and whether or not it is active (see 
Table 3). Normally, only the operator 
is able to modify the SST (for exam- 
ple when you subscribe to an extra 
service). In our case the SST is not 
write-protected, but you should 
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refrain from writing random values 
into it! Its original contents (DF 30 
C3 F3 00 00 00 03) are a mirror image 
of the capabilities offered by the 
selected files. Attempts to activate 
services on the card that it doesn’t 
support are pointless. On the other 
hand, it is possible to deactivate one 
of the services by turning one of the 
original ‘1’ bits into a ‘0’. 


Table 3. 


The services in the SIM Service Table. 


Byte Active Present Service 
b2 bl Service 

il b4 b3 Service 
b6 b5 Service 

b8 b7 Service 

b2 b1 Service 

2 b4 b3 Service 
b6 b5 Service 

b8 b7 Service 

b2 b1 Service 

3 b4 b3 Service 
b6 b5 Service 

b8 b7 Service 

b2 b1 Service 

4 b4 b3 Service 
b6 b5 Service 

b8 b7 Service 

b2 b1 Service 

5 b4 b3 Service 
b6 b7 Service 

b8 b7 Service 

b2 b1 Service 

6 b4 b3 Service 
b6 b5 Service 

b8 b7 Service 

b2 bl Service 

7 b4 b3 Service 
b6 b5 Service 

b8 b7 Service 

b2 bl Service 

8 b4 b3 Service 
b6 b5 Service 

b8 b7 Service 

b2 bl Service 

9 b4 b3 Service 

RFU = 
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In the same way we can tem- 
porarily change phase 03h into 
phase 02h, to study the conse- 
quences. 

ICCID contains the (not confiden- 
tial) identification number of the 
card; IMSI identifies the subscriber 
via the network operator (the phone 
number, really...). IMSI also contains 
the code of the operator, allowing 


GSM 


1; 
23 


3: 
4: 


Dis 
6: 


7: 
8: 


Os 
Os) 
EA 
23 


T35 
14: 


15i 
16: 


Was 
18: 
19: 
20: 


25: 

26: 
27: 

28: 


29: 
20% 


Silke 
BAG 


33% 
34: 


CHV (PIN)1 disable function 

Abbreviated Dialling Numbers 
(ADN) 

Fixed Dialling Numbers (FDN) 

Short Message Storage (SMS) 


Advice of Charge (AoC) 

Capability Config. Parameters 
(CCP) 

PLMN Selector 

Party Subaddress 


MSISDN 
Extension 1 
Extension 2 
SMS Parameters 


Last Number Dialled (LND) 

Cell Broadcast Message Identi- 
fier 

Group Identifier Level 1 

Group Identifier Level 2 


Service Provider Name 

Service Dialling Numbers (SDN) 
Extension 3 

RFU 


: VCGS Group Identifier List (EF 


VGCS and EF VGCSS) 


: VBS Group Identifier List (EF 


VBS and EF VBSS ) 


: Enhanced Multi-Level Precedence 


& Pre-emption Service 


: Automatic Answer for eMLPP 


Data download via SMS-CB 


Data download via SMS-PP 
Menu selection 


Call control 


Proactive SIM 

Cell Broadcast Message Identi- 
fier Ranges 

Barred Dialling Numbers (BDN) 

Extension 4 


De-personalization Control Keys 
Co-operative Network List 


Reserved for Future Use 


the possibility of ‘roaming’: When a network 
comes across an unfamiliar IMSI, it requests 
permission from the operator of the SIM card 
for the subscriber to use its services. If 
granted, the logo of this network will appear 
on the display. In our case the original net- 
work code is 001-01, a value for a fictional 
network and reserved for our SIM test card. 

The AD file is also programmed with a typ- 
ical test value. The advantage of this is that 
the card won't be rejected by a phone which 
has a ‘simlock’ added by the service provider. 

The GID1 and GID2 files have similar roles. 
Some phones will only accept SIM cards con- 
taining a certain value in these, normally 
write-protected, files. 

The contents of LOCI become apparent 
when you manually try to connect the phone 
to a network. The attempt is bound to fail 
because the identification inside the SIM card 
is fictional. In this file we can find the code of 
the last operator with which contact was 
attempted, as well as some details regarding 
the place of the attempt and the reason for 
the failure of the connection. At the same 
time, the code of every network that rejected 
the SIM card is stored in the file FPLMN, up 
to a maximum of four. The list can be cleared 
by setting all bytes in FPLMN to FFh. 

Most of the files in the Telecom directory 
are concerned with personal details of the 
subscriber, such as lists with phone numbers 
and SMS messages. The menu of virtually 
every phone offers the opportunity to modify 
the contents of these files, but there are also 
programs for the PC that are much easier to 
use. 


Utilities 

In principle any asynchronous card reader 
could be used to modify the contents of our 
cards via the PC’s keyboard, using the active 
low ISO7816 instructions. For example, in 
order to write 02h to the ‘Phase’ byte, the fol- 
lowing instructions would have to be exe- 
cuted: 


AO A4 00 00 02 3F 00 
AO A4 00 00 01 7F 20 
AO A4 00 00 02 6F AE 
AO D6 00 00 01 02 


There are also programs for the manage- 
ment of SIM cards that are much easier to 
use, thanks to a built-in editor. One of the 
best examples of this is SIMSurf Profi, which 
is included with certain versions of ChipDrive 
card readers by Towitoko (www.towitoko.de). 

These readers are very popular in Europe 
and can be set up to work in either PC or SC 
mode (by installing its drivers). They are also 
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Table 4. Explanation of the 
‘Terminal Profile’ structure. 


Byte I: 


Bit 
Bit 
Bit 
Bit 


Byte 2: 


Bit 
Bit 


Byte 3 ( 
Is 


Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 


Byte 4 ( 


Bit 
Bit 
Bit 
Bit 
Bit 
Bit 
Bit 


compatible with the utility program 
UTILPCSC.EXE, which is required for reading 
the LOG file of our experimental card. The 
programs UTIL1.EXE and UTIL2.EXE are 
meant to be used with the CyberMouse card 
readers (the ACR20S or the ACR305 from 
ACS), which are included with the BasicCard 


1 
2 


4 


: Profile download 

: SMS-PP data download 
a) g 
: Menu selection 


i g 


2 


OoN AUN SPwWwWHNY 


1 


OAN SPW ND 


Cell Broadcast data download 


Command result 


: Call Control by SIM 


Proactive SIM): 


Display Text 


: Get Inkey 

: Get Input 

: More Time 

: Play Tone 

: Poll Interval 
: Polling Off 

: Refresh 


Proactive SIM): 

: Select Item 

: Send Short message 

: Send SS 

: Send USSD 

: Setup Call 

: Setup Menu 

: Provide Local Information 


kits (www.basiccard.com). 


The various utilities mentioned 
here, as well as the TPIMG file that 
has to be stored on the ZC4.1 SIM 
card, can be downloaded from the 
Elektor Electronics website 
(www.elektor-electronics.co.uk). They 
can also be ordered from Elektor 
Electronics (on floppy disk, order 
number 010138-11). 

With a special driver (found at 
www.acs.com.hk) the program 
UTILPCSC.EXE can be used. This 
program, which like the SIM card 
has been developed in ZCBasic V4, 
provides four fundamental functions 
for use with the LOG file: Activate, 
deactivate, download and clear. In 
general, the LOG file is activated just 
before insertion of the SIM card in a 
GSM phone and deactivated imme- 
diately after its removal, in order to 
prevent the overflow of data on the 
card. 

We download the file (which is 
stored on the hard drive with the 
name CARD.LOG) and clear the con- 
tents of the card to make room for 
new information. CARD.LOG is an 
ASCII file that contains hexadecimal 
values. This can be viewed using 
any editor or word processor. Every 
instruction received by the card is 
put on a new line, while a blank line 
indicates that the card was reset at 
that point (for example, by switching 
the phone off, and then on again). 

The information shown below 
was captured when a Phase 2+ 
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compatible phone was activated. 
The ‘Terminal Profile’ instruction at 
the end of the file is used by the 
phone to inform the card of its capa- 
bilities. 


AO A4 00 00 02 
AO CO 00 00 16 
AO A4 00 00 02 6F AE 

AO CO 00 00 OF 

AO BO 00 00 01 

AO A4 00 00 02 6F 05 

AO CO0 00 00 OF 

AO BO 00 00 03 

AO A4 00 00 02 6F 05 

AO CO 00 00 OF 

AO A4 00 00 02 7F 20 

AO CO 00 00 16 

AO A4 00 00 02 6F AE 

AO CO 00 00 OF 

AO BO 00 00 01 

AO 10 00 00 04 OF 03 FF F7 


7F 20 


The hexadecimal string OF 03 FF 
F7 appears on the display of the 
mobile after the initialisation proce- 
dure (those long delays which are 
often followed by the message ‘try 
again later’ when you try to execute 
a function that requires too many 
system resources). 

A quick glance at the information 
in Table 4 (based on the GSM 11.14 
specification) tells us that this phone 
possesses all SIM Toolkit functions, 
apart from the ‘Send USSD’ function. 
Furthermore, we can tell that this 
device is incompatible with several 
advanced functions (sending SMS 
and email) and that this is a particu- 
lar international prepaid SIM card, 
the EasyRoam GSM card from Swiss- 
com (www.easy-roam.com). Every 
phone model will give different 
results, which can also vary depend- 
ing on the location or country. 

(010138-1 


Editor’s note: 

Unfortunately the BasicCard used for 
this project has a relatively high price: 
nearly 10 US$ per card with a mini- 
mum order quantity of ten pieces. For 
readers who are interested in the card 
we would suggest that they band 
together and place a combined order 
with the supplier. 
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Although this project was developed using a BasicCard kit V4.12, you don’t 
need the complete kit to build and use the SIM card emulator. 
In practice it is sufficient to have the following items: 


— the program BCLOAD.EXE, which is pot of the free development kit that 
can be downloaded from ; 

— a compatible Smartcard reader, such a as Te Se that is included 
with the BasicCard kit, or another PC/SC reader 

—a blank BasicCard that can accept our TPIMG program file (Currently that is 
a ZC4.1 RSA [28/09/2001]) 


When the Smartcard reader has been installed according to the manufac- 
turer’s instructions, you should open an MS-DOS window and change to the 
directory that contains the files TRIMG and BCLOAD.EXE. 

One of the following commands should now be typed: 


—BCLOAD -D -P| TPIMG when using a CyberMouse on COMI, 

—BCLOAD -D -P2 TPIMG when using a CyberMouse on COM2, 

—BCLOAD -D -P101 TRIMG when using a PC/SC compatible reader, regard- 
less of the port that it is connected to. 


When the reader has been recognised a request appears on the screen to 
insert a blank card (SCreendump A). Should the file turn out to be incom- 
patible with the card, the program BCLOAD will issue a warning (Screen- 
dump B), otherwise the progress is indicated on the screen by a series of 
addresses as they are programmed. Wait until the programming has com- 
pleted before removing the card (Screendump C). 

The card should now be initialised with the ‘Clear LOG file’ function of our 
program. The first time round this can take quite some time 
(Screendump D)! 


Three different programs are available: 
— UTILI.EXE for use with a CyberMouse on COMI 
— UTIL2.EXE for use with a CyberMouse on COM2 
— UTILPCSC.EXE for use with a PC/SC reader 


The only thing left to do is to cut the SIM card to size, after which it can be 
inserted into a GSM phone. 

Figure I shows all dimensions, in case that the BasicCard has not been 
pre-punched (this depends on the version). If enough care is taken during the 
removal of the chip, it will be possible to re-insert it back into the card. It can 
then be kept in place with some sticky tape. The card can then be put back 
into the reader for the extraction of the next set of information provided by 
the phone. 

For that matter, there are adapters for sale that take SIM cards and change 
them to Smartcard dimensions, allowing them to be easily inserted into the 

card reader on the PC. 
aan ae Sia aaa 1 The programs 
Lett edge ane that have been installed in 
the BasicCard directory 
as part of the Develop- 
ment Environment offer 
many other possibilities. 
For example, we can 
obtain further details of 
the cards that are 
inserted into the reader 
(Screendump E). We 
hope that you will enjoy 


4.0 max 
6.0 min 
11.62 max 
13.62 min 
(6.25) „l 
experimenting with this 


Figure |. Dimensions of a SIM card. powerful tool. 
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